<!-- meta page description: GRASS startup program -->

<h2>SYNOPSIS</h2>

<b>grass</b> [<b>-h</b> | <b>-help</b> | <b>--help</b>] [<b>-v</b> | <b>--version</b>] |
[<b>-c</b> | <b>-c geofile</b> | <b>-c EPSG:code[:datum_trans]</b>] | <b>-e</b> | <b>-f</b> |
[<b>--text</b> | <b>--gtext</b> | <b>--gui</b>] | <b>--config</b> |
[<b>--tmp-location</b> | <b>--tmp-mapset</b>]
    [[[<b>&lt;GISDBASE&gt;/</b>]<b>&lt;LOCATION&gt;/</b>]
    	<b>&lt;MAPSET&gt;</b>]
[<b>--exec EXECUTABLE</b>]

<h3>Flags:</h3>

<dl>

<dt><b>-h</b> | <b>-help</b> | <b>--help</b>
<dd> Prints a brief usage message and exits

<dt><b>-v</b> | <b>--version</b>
<dd> Prints the version of GRASS and exits

<dt><b>-c</b>
<dd> Creates new GRASS unprojected location in specified GISDBASE

<dt><b>-c geofile</b>
<dd> Creates new GRASS projected location in specified GISDBASE based on georeferenced file

<dt><b>-c EPSG:code</b>
<dd> Creates new GRASS projected location in specified GISDBASE with given EPSG code

<dt><b>-c EPSG:code:datum_trans</b>
<dd> Creates new GRASS projected location in specified GISDBASE with given EPSG code and datum transform parameters

<dt><b>-e</b>
<dd> Exit after creation of location or mapset. Only with <b>-c</b> flag

<dt><b>-f</b>
<dd> Forces removal of .gislock if exists (use with care!). Only with --text flag

<dt><b>--text</b>
<dd> Indicates that Text-based User Interface should be used (skip welcome screen)

<dt><b>--gtext</b>
<dd> Indicates that Text-based User Interface should be used (show welcome screen)

<dt><b>--gui</b>
<dd> Indicates that Graphical User Interface
(<em><a href="wxGUI.html">wxGUI</a></em>) should be used

<dt><b>--config</b>
<dd> Prints GRASS configuration parameters (options: arch, build, compiler, date, path, revision, svn_revision, version)

<dt><b>--exec EXECUTABLE</b>
<dd> Execute GRASS module or script. The provided executable will be executed in a GRASS GIS non-interactive session.

<dt><b>--tmp-location</b>
<dd> Run using a temporary location which is created based on the given
coordinate reference system and deleted at the end of the execution
(use with the --exec flag).
The active mapset will be the PERMANENT mapset.

<dt><b>--tmp-mapset</b>
<dd> Run using a temporary mapset which is created in the specified
location and deleted at the end of the execution
(use with the --exec flag).

</dl>

<h3>Parameters:</h3>

<dl>
<dt><b>GISDBASE</b>
<dd> Initial database directory which should be a fully qualified path
    (e.g., <tt>/usr/local/share/grassdata</tt>)

<dt><b>LOCATION</b>
<dd> Initial location directory which is a subdirectory of GISDBASE

<dt><b>MAPSET</b>
<dd> Initial mapset directory which is a subdirectory of LOCATION
</dl>

<i>Note</i>: These parameters must be specified in one of the
following ways:

<div class="code"><pre>
    MAPSET
    LOCATION/MAPSET
    GISDBASE/LOCATION/MAPSET
</pre></div>

<h2>DESCRIPTION</h2>

<p>This command is used to launch GRASS GIS. It will parse the command
line arguments and then initialize GRASS for the user. Since GRASS
modules require a specific environment, this program must be called
before any other GRASS module can run. The command line arguments are
optional and provide the user with a method to indicate the desired
user interface, as well as the desired mapset to work on.

<p>The startup program will remember both the desired user interface
and mapset. Thus, the next time the user runs GRASS, typing
<em>grass</em> (without any options) will start GRASS with the
previous settings for the user interface and mapset selected.

<p>If you specify a graphical user interface (<b>--gui</b>)
the <em>grass</em> program will try to verify that the system you
specified exists and that you can access it successfully. If any of
these checks fail then <em>grass</em> will automatically switch back
to the text user interface mode.

<h3>Running non-interactive jobs</h3>

The <b>--exec</b> flag can run an executable on path, GRASS module, or a script.
All are executed as a subprocess and any additional arguments are passed to it.
A script needs to be specified by full or relative path and on unix-likes systems,
the script file must have its executable bit set. Calling the interpreter
(e.g., <code>python</code>) and providing the script as a parameter is possible, too.
When it is finished GRASS will automatically exit using the return code given
by the subprocess. Although the execution itself is non-interactive (no GUI or shell),
the subprocess itself can be interactive if that is what the user requires.

<h3>Config flag</h3>

The flag <b>--config option</b> prints GRASS GIS configuration and
version parameters, with the options:

<ul>
<li><b>arch</b>: system architecture (e.g., <tt>x86_64-pc-linux-gnu</tt>)</li>
<li><b>build</b>: (e.g., <tt>./configure --with-cxx --enable-largefile --with-proj [...]</tt>)</li>
<li><b>compiler</b>: (e.g., <tt>gcc</tt>)</li>
<li><b>date</b>: (e.g., <tt>Tue Mar 31 20:34:57 2020 +0200</tt>)</li>
<li><b>path</b>: (e.g., <tt>/usr/lib64/grass</tt>)</li>
<li><b>revision</b>: (e.g., <tt>745ee7ec9</tt>)</li>
<li><b>svn_revision</b>: (e.g., <tt>062bffc8</tt>)</li>
<li><b>version</b>: (e.g., <tt>8.0.0dev</tt>)</li>
</ul>


<h2>SAMPLE DATA</h2>

The GRASS GIS project provides several free sample geospatial datasets
as ready-to-use locations. They are available to download at
<a href="https://grass.osgeo.org/download/sample-data/">https://grass.osgeo.org/download/sample-data/</a>.

The "North Carolina data set" is a modern package of geospatial data from
North Carolina (USA), and it includes raster, vector, LiDAR and satellite
data. This is the most extensively used data set in the documentation and
the examples throughout the user manual pages are based upon it.

<h2>ENVIRONMENT VARIABLES</h2>

A number of environment variables are available at GRASS startup to
assist with automation and customization. Most users will not need to
bother with these.

<p>In addition to these shell environment variables GRASS maintains a
number of GIS environment variables in the <tt>$HOME/.grass8/rc</tt>
file. User changes to this file will be read during the next startup
of GRASS. If this file becomes corrupted the user may edit it by hand
or remove it to start afresh.  See the list
of <em><a href="variables.html">implemented GRASS variables</a></em>
for more information.  The rest of this help page will only consider
shell environment variables.

<p>Note that you will need to set these variables using the
appropriate method required for the UNIX shell that you use (e.g. in a
Bash shell you must <tt>export</tt> the variables for them to
propagate).

<h3>User Interface Environment Variable</h3>

<p>The <em>grass</em> program will check for the existence of an
environment variable called GRASS_GUI which indicates the type of user
interface for GRASS to use. If this variable is not set
when <em>grass</em> is run, then it will be created and then saved
in the <tt>$HOME/.grass8/rc</tt> file for the next time GRASS is
run. It can be set to <tt>text</tt>, <tt>gtext</tt> or <tt>gui</tt>.

<p>There is an order of precedence in the way <em>grass</em>
determines the user interface to use. The following is the hierarchy
from highest precedence to lowest.
<ol>
  <li>Command line argument
  <li>Environment variable GRASS_GUI
  <li>Value set in <tt>$HOME/.grass8/rc</tt> (GUI)
  <li>Default value - <tt>gui</tt>
</ol>

<h3>Python Environment Variables</h3>

<p>If you choose to use <em><a href="wxGUI.html">wxGUI</a></em>
interface, then the GRASS_PYTHON environment variable can be used to
override your system default <tt>python</tt> command.

<p>Suppose for example your system has Python 3.6 installed and you
install a personal version of the Python 3.8 binaries
under <tt>$HOME/bin</tt>. You can use the above variables to have
GRASS use the Python 3.8 binaries instead.

<div class="code"><pre>
   GRASS_PYTHON=python3.8
</pre></div>

<h3>Addon Path to Extra User Scripts</h3>

This environment variable allows the user to extend the GRASS program
search paths to include locally developed/installed GRASS modules or
user scripts.

<div class="code"><pre>
   GRASS_ADDON_PATH=/usr/mytools
   GRASS_ADDON_PATH=/usr/mytools:/usr/local/othertools
</pre></div>

<p>In this example above path(s) would be added to the standard GRASS path
environment.

<h3>Addon Base for Extra Local GRASS Addon Modules</h3>

This environment variable allows the user to extend the GRASS program
search paths to include locally installed
(see <em><a href="g.extension.html">g.extension</a></em> for details)
<a href="https://grasswiki.osgeo.org/wiki/GRASS_AddOns">GRASS Addon</a>
modules which are not distributed with the standard GRASS release.
<div class="code"><pre>
   GRASS_ADDON_BASE=/usr/grass-addons
</pre></div>

<p>In this example above path would be added to the standard GRASS
path environment.

<p>If not defined by user, this variable is set by GRASS startup program
to <tt>$HOME/.grass8/addons</tt> on GNU/Linux
and <tt>%APPDATA%\Roaming\GRASS8\addons</tt> on MS Windows.

<h3>HTML Browser Variable</h3>

The GRASS_HTML_BROWSER environment variable allows the user to set the
HTML web browser to use for displaying help pages.

<h2>EXAMPLES</h2>

<p>The following are some examples of how you could start GRASS

<dl>
<dt><b>grass</b>
<dd> Start GRASS using the default user interface. The user will be
    prompted to choose the appropriate location and mapset.

<dt><b>grass --gui</b>
<dd> Start GRASS using the graphical user interface. The user will be
    prompted to choose the appropriate location and mapset.

<dt><b>grass --text</b>
<dd> Start GRASS using the text-based user interface. Appropriate
location and mapset must be set by environmental variables (see
examples below) otherwise taken from the last GRASS session.</dd>

<dt><b>grass --gtext</b>
<dd> Start GRASS using the text-based user interface. The user will be
    prompted to choose the appropriate location and mapset.

<dt><b>grass $HOME/grassdata/spearfish70/user1</b>
<dd> Start GRASS using the default user interface and automatically
    launch into the given mapset, bypassing the mapset selection menu.

<dt><b>grass --gui -</b>
<dd> Start GRASS using the graphical user interface and try to
    obtain the location and mapset from environment variables.

<dt><b>grass -c EPSG:4326 $HOME/grassdata/mylocation</b>
<dd> Creates a new GRASS location with EPSG code 4326 (latitude-longitude, WGS84)
    in the specified GISDBASE

<dt><b>grass -c EPSG:5514:3 $HOME/grassdata/mylocation</b>
<dd> Creates a new GRASS location with EPSG code 5514 (S-JTSK / Krovak
    East North - SJTSK) with datum transformation parameters used in
    Czech Republic in the specified GISDBASE

<dt><b>grass -c XY $HOME/grassdata/gnomonic --exec g.proj -c proj4='+proj=gnom +lat_0=90 +lon_0=-50'</b>
<dd>  Creates a new GRASS location from PROJ definition string
    (here: <a href="https://proj4.org/operations/projections/gnom.html">gnomonic</a>)
    in the specified GISDBASE

<dt><b>grass -c myvector.shp $HOME/grassdata/mylocation</b>
<dd> Creates a new GRASS location based on georeferenced Shapefile

<dt><b>grass -c myraster.tif $HOME/grassdata/mylocation</b>
<dd> Creates a new GRASS location based on georeferenced GeoTIFF file
</dl>

<h3>Batch jobs with the exec interface</h3>

<!--
Data created with:
r.out.gdal input=elevation output=elevation.tiff
r.out.gdal input=basin_50K output=basins.tiff
Region issues ignored.
-->

Creating a new Location based on a geodata file's projection (<b>-c</b>)
and exit (<b>-e</b>) immediately:

<div class="code"><pre>
grass -c elevation.tiff -e /path/to/grassdata/test1/
</pre></div>

Linking external raster data to PERMANENT Mapset:

<div class="code"><pre>
grass /path/to/grassdata/test1/PERMANENT/ --exec r.external input=basins.tiff output=basins
grass /path/to/grassdata/test1/PERMANENT/ --exec r.external input=elevation.tiff output=elevation
</pre></div>

Get statistics for one raster map:

<div class="code"><pre>
grass /path/to/grassdata/test1/PERMANENT/ --exec r.univar map=elevation
</pre></div>

Compare the rasters visually:

<div class="code"><pre>
grass /path/to/grassdata/test1/PERMANENT/ --exec g.gui.mapswipe first=elevation second=basins
</pre></div>

<h4>Execution of shell and Python scripts instead of single commands</h4>

A sequence of commands can be bundled in a script and executed using the
exec interface.
<p>
<b>Shell script example:</b> the command to execute a shell script might be:

<div class="code"><pre>
grass /path/to/grassdata/test1/PERMANENT/ --exec sh test.sh
</pre></div>

A very simple bash script ("test.sh") may look like this:

<div class="code"><pre>
#!/bin/bash

g.region -p
g.list type=raster
r.info elevation
</pre></div>

<p>
<b>Python script example:</b> the command to execute a Python script might be:

<div class="code"><pre>
grass /path/to/grassdata/test1/PERMANENT/ --exec python test.py
</pre></div>

A very simple Python script ("test.py") may look like this:

<div class="code"><pre>
#!/usr/bin/env python3

# import GRASS Python bindings (see also pygrass)
import grass.script as gs
import grass.script.setup as gsetup

gs.message('Current GRASS GIS 8 environment:')
print(gs.gisenv())

gs.message('Available raster maps:')
for raster in gs.list_strings(type='raster'):
    print(raster)

gs.message('Available vector maps:')
for vector in gs.list_strings(type='vector'):
    print(vector)
</pre></div>

<h4>Using temporary location</h4>

Creating a new temporary location based on a georeferenced file's
projection coordinate reference system (CRS) and simultaneously starting
computation in a shell script:

<div class="code"><pre>
grass --tmp-location elevation.tiff --exec test.sh
</pre></div>

The same, but using an EPSG code and a Python script:

<div class="code"><pre>
grass --tmp-location EPSG:3358 --exec test.py
</pre></div>

Finally, for special cases, we can create an XY location without any CRS:

<div class="code"><pre>
grass --tmp-location XY --exec test.py
</pre></div>

Temporary location is automatically deleted after computation,
so the script is expected to export, link or otherwise preserve the
output data before ending.

<p>
A single command can be also executed, e.g. to examine properties of the
temporary location:

<div class="code"><pre>
grass --tmp-location EPSG:3358 --exec g.proj -p
</pre></div>

A temporary XY location with single command is useful, e.g. to show
help text of a module:

<div class="code"><pre>
grass --tmp-location XY --exec r.neighbors --help
</pre></div>


<h4>Using temporary mapset</h4>

<p>
A single command can be executed, e.g., to examine properties of a
location (here using the NC SPM sample location):

<div class="code"><pre>
grass --tmp-mapset /path/to/grassdata/nc_spm_08/ --exec g.proj -p
</pre></div>

Computation in a Python script can be executed in the same way:

<div class="code"><pre>
grass --tmp-mapset /path/to/grassdata/nc_spm_08/ --exec processing.py
</pre></div>

Additional parameters are just passed to the script, so we can run the
script with different sets of parameters (here 5, 8 and 3, 9) in
different temporary mapsets which is good for parallel processing.

<div class="code"><pre>
grass --tmp-mapset /path/to/grassdata/nc_spm_08/ --exec processing.py 5 8
grass --tmp-mapset /path/to/grassdata/nc_spm_08/ --exec processing.py 3 9
</pre></div>

The same applies to Bash scripts (and other scripts supported on you
platform):

<div class="code"><pre>
grass --tmp-mapset /path/to/grassdata/nc_spm_08/ --exec processing.sh 5 8
</pre></div>

The temporary mapset is automatically deleted after computation,
so the script is expected to export, link or otherwise preserve the
output data before ending.


<h4>Troubleshooting</h4>
Importantly, to avoid an <tt>"[Errno 8] Exec format error"</tt> there must be a 
<a href="https://en.wikipedia.org/wiki/Shebang_%28Unix%29">shebang</a> line at the top of
the script (like <tt>#!/bin/sh</tt>, <tt>#!/bin/bash</tt>, or <tt>#!/usr/bin/env python3</tt>)
indicating which interpreter to be used for the script. The script file must 
have its executable bit set. 

<h2>CAVEAT</h2>

If you start GRASS using the <em><a href="wxGUI.html">wxGUI</a></em>
interface you must have a <tt>python</tt> command in your $PATH
variable. That is, the command must be named
<tt>python</tt> and not something like <tt>python3.6</tt>. Rarely some
Python installations do not create a <tt>python</tt> command. In these
cases you can override <tt>python</tt> by GRASS_PYTHON environmental
variable.

<p>Furthermore, if you have more than one version of Python installed,
make sure that the version you want to use with GRASS is set by
GRASS_PYTHON environmental variable.

<h2>SEE ALSO</h2>

List of <a href="variables.html">GRASS environment variables</a>

<p>
<a href="https://grass.osgeo.org">GRASS GIS Web site</a><br>
<a href="https://grasswiki.osgeo.org/wiki/">GRASS GIS User Wiki</a><br>
<a href="https://github.com/OSGeo/grass/issues">GRASS GIS Bug Tracker</a><br>
<a href="https://grass.osgeo.org/programming8/">GRASS GIS 8 Programmer's Manual</a>

<h2>AUTHORS (of this page)</h2>

Justin Hickey<br>
Markus Neteler<br>
Hamish Bowman<br>
Martin Landa, Czech Technical University in Prague, Czech Republic

<!--
<p>
<i>Last changed: $Date$</i>
-->
